1. Field of the Invention
This disclosure relates to a Push-To (PT) (e.g., Push-To-Talk, Push-To-View or Push-To-Data) service, and more particularly, to a method and device for controlling a floor (talk burst authority or media burst authority, permission to send media burst, etc.) in a PT service.
2. Discussion of the Related Art
A PT service is a type of half duplex communication service, such as a PTT (Push to Talk) for providing call services by sending voice (audio) data, a PTV (Push to View) for sending image (video) data, and a PTD (Push to Data) for sending various data. Among clients participated in a session established via a server in the PT service, one client having a talk burst authority (or media burst authority or floor) or a permission to send media burst sends media data (e.g., talk burst or media burst) including audio or video and then the remaining clients participated in the session receive the sent media data.
A PT client in the PT service can communicate with a plurality of different PT clients without having to perform a dialing process, a waiting process for call connection and a call connection tone providing process, so that it can support a fast communications service compared with an ordinary mobile communications terminal. Also, the PT service can send a user's voice and data to a single recipient (1-to-1) or to groups of recipients (1-to-many) as in a group chat session.
The related art PT service comprises selecting, by a specific client, one or more other clients and inviting them in a PT session, establishing a session between the inviting client (originating client) and the invited clients (terminating clients), and transmitting/receiving voice (audio) and/or other data between the clients having the session established therebetween.
In the PT service, before a user sends media data such as audio, video or other data via his PT terminal, the user must request a permission to send media data (or talk burst authority or media burst authority or floor, which can be referred to as ‘media burst authority’ hereafter) from a PT server (e.g., PoC (Push to Talk over Cellular) server). The user can send the media data after being granted the media burst authority from the PT server. As such, controlling the media burst authority of the user's terminal is referred to as Talk Burst Control (or Media Burst Control). In addition, regarding this media burst control, the media burst authority with which a specific user can send media data via a communication channel can be restricted, function of which is called ‘Talk Burst Revoke’.
FIG. 1 is a state transition (state machine) diagram of a PT server (from the perspective of the PT server) for a media burst operation to a PT client according to a related art. FIG. 1 illustrates each state of the PT server for media burst (or talk burst) operations to the PT client (i.e., terminal). States illustrated in oval shape in FIG. 1 may be classified into a stable state and a transition state depending on the characteristic of each state. Events are indicated in boxes in FIG. 1.
Relevant states illustrated in FIG. 1 are described as follows.
(a) ‘Start-stop’ state denotes a state in which no SIP (Session Initiation Protocol) session exists between a PT server and an associated PT client. Hereinafter, this ‘Start-stop’ state is referred to as ‘0 (zero) state’.
(b) A state ‘U: not permitted and MB_Idle’ is a stable state, and denotes a state in which a PT server can receive a talk burst (media burst) authority request from a PT client. In other words, it is a state in which the PT client can send a talk burst (media burst) request (referred to as ‘MB_Request) in order to send media burst to the PT server. Hereinafter, the state ‘U: not permitted and MB_Idle’ is referred to as a ‘first state’.
(c) A state ‘U: permitted’ is a stable state, and denotes a state in which a PT server has granted the permission to send a media burst to an associated PT client so that the associated PT client can send the media burst to the PT server. Hereinafter, this state ‘U: permitted’ is referred to as a ‘second state’. In this state, the PT server operates (starts) a T1 timer (i.e., End of RTP media timer) and a T2 timer (i.e., Stop talking timer). These timers will be explained later.
(d) A state ‘U: not permitted but sends media’ is a transition state, and denotes a state in which a PT server receives media date (or RTP media packets) from a PT client that does not have a talk burst authority. Hereinafter, this state ‘U: not permitted but sends media’ is referred to as a ‘third state’. In this state, the PT server operates/starts a T8 timer (i.e., media burst revoke timer).
(e) A state ‘U: pending MB_Revoke’ is a transition state, and a PT server uses this state during a grace period after sending an MBCP (Media Burst Control Protocol) Media Burst Revoke message. Hereinafter, this state ‘U: pending MB_Revoke’ is referred to as a ‘fourth state’. In this state, the PT server operates/starts a T3 timer (i.e., Start talking grace timer), and a period for which the T3 timer is running corresponds to the grace period.
(f) A state ‘U: waiting MB_Revoke’ is a stable state, and denotes a state in which a PT serve does not grant a permission to send a media burst requested by an associated PT client for a certain period for which a T9 timer is operated/running. When the associated PT client continues sending media data beyond a period of the permission to send the media burst (i.e., a period for which the T2 timer is running until it expires), the PT server panelizes the associated PT client. In this state, the PT server operates/starts the T9 timer (i.e., retry-after timer). Hereinafter, this state ‘U: waiting MB_Revoke’ is referred to as a ‘fifth state’.
(g) A state ‘U: not permitted and MB_Taken’ is a stable state, and denotes a state in which when another PT client (i.e., not associated PT client), other than the associated PT client which has been permitted to send a media burst, requests the permission to send a media burst, a PT server informs the another PT client that the permission to send the media burst is taken. Hereinafter, this state ‘U: not permitted and MB_Taken’ is referred to as a ‘sixth state’.
The timers T1, T2, T3, T8 and T9 introduced in the above description of FIG. 1 are used in order to restrain or control the sending of media burst (MB) between the PT server and the associated PT client(s). Hereinafter, the operations of these timers are described. Generally, media data sent from a PT client to a PT server is sent in a RTP (Real Time Protocol) packet format.
T1 Timer (End of RTP Media timer)
T1 timer is adapted to count whether a PT server has received a succeeding RTP packet within an available time period after receiving a preceding RTP packet. The T1 timer is generally set to 4 seconds as its a default value. After a terminal sends media data, namely, RTP media packets, to a PT server, when the PT server receives a first RTP packet, the T1 timer is started, and it is restarted whenever a following RTP packet is received. When the PT server receives the last RTP packet, the T1 timer is stopped or expires.
T2 Timer (Stop talking timer)
T2 timer is adapted to count a permitted (authorized) period for which a terminal having a permission to send a media burst (floor or talk burst authority) can send media data. When the terminal sends a first RTP packet, the PT server starts the T2 timer. The T2 timer is generally defaulted to 30 seconds.
T3 Timer (Stop talking grace timer)
T3 timer is adapted to count a grace period for which the PT server can further receive media data even after the T2 timer expires. Here, the grace period refers to a kind of a marginal excess time for which the PT server is allowed to receive media data even after the T2 timer expires. That is, even if the terminal having the permission to send the media burst has sent the media data after the period for which the terminal is permitted to send the media data, the PT server permits the media data received from the terminal during the set period of the T3 timer, i.e., before the T3 timer expires.
T9 Timer (Retry-after timer)
T9 timer is adapted to count a penalty time given to a terminal when it sends the media data beyond a permitted period, the penalty time for which the terminal can not be permitted to request the media burst authority to PT server. When the terminal sends the media data beyond (after) a value (time period) set by the T2 timer (i.e., after a permitted period for sending the media data), the PT server sends a MBCP Revoke message or TBCP Revoke message to the terminal and then starts the T3 timer. When the PT server may not receive a MBCP Release message or TBCP Release message from the terminal during the time set by the T3 timer, it starts the T9 timer so that the terminal is not permitted to request the media burst authority and send the media data for a certain period corresponding to the time value set by the T9 timer (i.e., during the running period of the T9 timer).
T8 Timer (Talk Burst Revoke timer)
T8 timer is started at the time of sending a MB_Revoke message by the PT server. When the terminal has not sent a MB_Release message within a value (i.e., time period) set by the T8 timer, the PT server restarts the T8 timer to wait to receive the MB_Release message being sent by the terminal.
FIG. 2 is a signal flowchart illustrating acquisition of a permission to send a media burst and transmission of media data between a PT server and terminals according to a related art.
Hereinafter, description is provided with reference to FIGS. 1 and 2. Here, it is assumed that a SIP session was initiated in the zero state of the PT server in FIG. 1, and then the PT sever has been transited (changed) into the first state by sending a MB_Idle message to each terminal (PT client device). That is, the PT server is in a state in which each terminal can request a permission (i.e., media burst authority) to send a media burst from the PT server.
Each of terminals A, B and C sends to the PT server a message for requesting a floor (media burst authority or talk burst authority) or a permission to send a media burst (i.e., MB_Request) (S1). If the PT server has decided to grant a permission to send the media burst to the terminal A, the PT server sends a MB_Granted message to the terminal A in response of the MB_Request message thereof. In the meantime, the PT server sends a message indicating the terminal A has taken the permission to send the media burst (i.e., MB_Taken) to the terminals B and C (S2). Through those steps S1 and S2, an operation state of the PT server with respect to the terminal A may be transited from the first state into the second state (i.e., state ‘U: permitted’) as illustrated in FIG. 1. Accordingly, the terminal A can now send media data (or RTP media packets) to the PT server within the period set by the T2 timer (i.e., during the running period of the T2 timer). Also, through steps S1 and S2, since the terminals B and C have received the MB_Taken message, the operation state of the PT server with respect to the terminals B and C corresponds to the sixth state (‘U: not permitted and MB_Taken’) as illustrated in FIG. 1.
Because the state of the PT server with respect to the terminal A in FIG. 1 corresponds to the second state (i.e., state ‘U: permitted’), the terminal A can send the media data (or RTP media packets) to the PT server (S3). Here, when receiving a first RTP media packet sent by the terminal A, the PT server may start both the T1 timer and the T2 timer simultaneously.
If the terminal A sends a message for releasing the permission to send the media burst (i.e., MB_Release message) within the period for which it is permitted to send the media data (i.e., within a value (time period) set by the T2 timer), the state of the PT server with respect to the terminal A may be transited from the second state into the first state as illustrated in FIG. 1. Also, the PT server may stop the running T2 timer (i.e., the T2 timer is stopped before it expires). However, if the period for which the terminal A is permitted to send the media data (i.e., the value (time period) set by the T2 timer) expires, the PT server sends a message for revoking the permission to send the media burst (i.e., MS_Revoke message) to the terminal A.
Generally, messages and media data (or RTP media packets) from a terminal may be sent via different network routing paths under a physical communication environment. However, such physical communication environment may include a transit delay while receiving the messages and the media data via different network routing paths. In addition, such situation may make the current state of the PT server with respect to the terminal to be the third state (e.g., ‘U: not permitted but sends media’) unintentionally in the state machine diagram of FIG. 1.
For instance, when the PT server is in the second state and then receives a MB_Release message from the terminal, the PT server transits from the second state to the first state. If the PT server then receives media data (RTP packet) that was sent out by the terminal earlier than the MB_Release message but arrived at the PT server later due to the delay in the routing path, then the PT server transits from the first state to the third state as shown in FIG. 1. But the third state is not desired at this time because the terminal cannot request a permission to send a media burst from the PT server in the third state, and the PT server needs to return to the first state in order for the terminal to be able to request a permission to send a media burst. Further, the PT server may not be able to return to the first state at that time because to do so, the PT server needs to receive another MB_Release message which is unlikely to happen at that time. As a result, the terminal according to the state machine diagram of FIG. 1 of the related art may be kept to remain in the unintended state (e.g., the third state) where it can not request a permission to send a media burst from the PT server, which is a problem.
For example, when RTP media packets and MB_Release message are sequentially sent by the terminal, the MB_Release message may be reached at the PT server earlier than the RTP media packets or vice versa. In that case, the PT server can receive a part of the RTP media packets (e.g., the last or another RTP media packet of the RTP media packets sent by the terminal) via certain network routing paths, after receiving the MB_Release message via other network routing paths. At this time, since the PT server has already received the MB_Release message, the state of the PT server with respect to the terminal in the state diagram of FIG. 1 is transited from the second state (i.e., ‘U: permitted’) into the first state (i.e., ‘U: not permitted and MB_Idle’). Afterwards, even if the PT server has received the last RTP media packet, it can not recognize that the received last RTP media packet has been sent earlier than the already received MB_Release message. Accordingly, the PT server determines that the terminal having no permission to send the media burst has sent the media data (i.e., the received last RTP media packet). Therefore, the PT server discards the received last RTP media packet and then sends a MB_Revoke message (indicating that the permission to send media burst granted to the terminal has been revoked) to the terminal (i.e., this corresponds to ‘Situation 1’ of FIG. 1). That is, in the state diagram of FIG. 1 according to the related art, the state of the PT server with respect to the terminal is changed from the first state (i.e., ‘U: not permitted and MB_’) into the third state (i.e., ‘U: not permitted but sends media’). Under the third state of FIG. 1, the PT server sends the MB_Revoke message to the terminal and simultaneously operates the T8 timer (i.e., this corresponds to ‘Situation 2’ of FIG. 1 ). However, Situation 2 is repeated until the PT server receives a MB_Release message from the terminal, and the state of the PT server with respect to the terminal may keep at the third state in the state machine diagram of FIG. 1. If Situation 2 is repeated, from the perspective of the terminal, the terminal may be unfavorably treated in that it can not request a media burst authority (the permission to send media burst) to the PT server in spite of having sent the MB_Release message previously. This is a problem which may occur due to the different network routing paths of the messages sent by the terminal.
In addition, because of the different network routing paths of the messages sent by the terminal, as a result the terminal may unintentionally reach the fifth state (i.e., U: waiting MB_Revoke) in the state diagram of FIG. 1. That is, after being granted the permission to send the media burst, the terminal (or PT client) may send the media data (i.e., series of RTP media packets) to the PT server during the permitted period for sending the media data (i.e., the time period corresponding to the set value of the T2 timer). In some cases, the series of RTP media packets sent by the terminal have sequence numbers. Also, information on the sequence number of the last RTP media packet may be included in the MB_Release message.
Although the terminal has sequentially sent the series of RTP media packets (i.e., media data) and the MB_Release message to the PT server within the set period on the T2 timer (e.g., 30 seconds), the messages (i.e. the RTP media packets and the MB_Release message) may be non-sequentially be received by the PT server, as compared to their sequential sending, because of their different network routing paths. For example, when RTP media packets and MB_Release message are sequentially sent, MB_Release message may be reached at the PT server earlier than the RTP media packets. That is, after receiving the MB_Release message sent by the terminal, the PT server may receive a part of the RTP media packets (e.g., the last RTP media packet of the RTP media packets sent by the terminal). Here, the PT server checks (i.e., retrieves and analyzes) the information on the sequence number of the last RTP media packet included in the MB_Release message, and then waits until the last RTP media packet is received. That is, the state of the PT server with respect to the terminal still stays in the second state (i.e., State ‘U: permitted’) of FIG. 1. However, if the T2 timer expires while the PT server waits to receive the last RTP media packet, the PT server sends the MB_Revoke message to the terminal (i.e., this corresponds to Situation 3 of FIG. 1). Here, the state of the PT server with respect to the terminal is transited from the second state into the fourth state (i.e., State ‘U: pending MB_Revoke’). Afterwards, upon receiving the last RTP media packet, the PT server may consider the last received RTP media packet as an invalid (not-permitted packet) that has not reached within the permitted time period for sending the media data (i.e., the set period of the T2 timer), and thereby penalizes the terminal. Accordingly, the state of the PT server with respect to the terminal is transited from the fourth state into the fifth state (i.e., State ‘U: waiting MB_Revoke’), namely, into the state in which the terminal is penalized (punished). That is, the terminal in the fifth state can not request a media burst authority to the PT server for the duration of the penalizing period (i.e., the time period corresponding to the set value of the T9 timer).
Accordingly, in a case where the terminal has sequentially sent RTP media packets (media data) and the MB_Release message within the permitted period for sending the media data (i.e., the time period set on by the T2 timer) (e.g., 30 seconds), if the permitted period for sending the media data elapses under the state that the PT server has first received the MB_Release message but has not received yet a part of the RTP media packets (e.g., the last RTP media packet) due to a transit delay on the network routing paths, the terminal may undesirably be in a state that it can not request media burst authority to the PT server for the time period set on the T9 timer (e.g., 30 seconds), which is not desired.